High Efficiency Video Coding (HEVC) is a new coding standard that has been developed in recent years. In the High Efficiency Video Coding (HEVC) system, the fixed-size macroblock of H.264/AVC is replaced by a flexible block, named coding unit (CU). Pixels in the CU share the same coding parameters to improve coding efficiency. A CU may begin with a largest CU (LCU), which is also referred as coded tree unit (CTU) in HEVC. In addition to the concept of coding unit, the concept of prediction unit (PU) is also introduced in HEVC. Once the splitting of CU hierarchical tree is done, each leaf CU is further split into one or more prediction units (PUs) according to prediction type and PU partition.
In the current development of screen content coding for High Efficiency Video Coding (HEVC) standard, some tools have been adopted due to their improvements in coding efficiency for screen contents. For Intra blocks, Intra prediction according to the conventional approach is performed using prediction based on reconstructed pixels from neighboring blocks. Intra prediction may select an Intra Mode from a set of Intra Modes, which include a vertical mode, horizontal mode and various angular prediction modes. For HEVC screen content coding, a new Intra coding mode, named Intra-block copy (IntraBC) has been used. The IntraBC technique that was originally proposed by Budagavi in AHG8. Video coding using Intra motion compensation, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 13th Meeting: Incheon, KR, 18-26 Apr. 2013, Document: JCTVC-M0350 (hereinafter JCTVC-M0350). An example according to JCTVC-M0350 is shown in FIG. 1, where a current coding unit (CU, 110) is coded using Intra MC (motion compensation). The prediction block (120) is located from the current CU and a displacement vector (112). In this example, the search area is limited to the current CTU (coding tree unit), the left CTU and the left-left CTU. The prediction block is obtained from the already reconstructed region. Then, the displacement vector, also named block vector (BV), and residual for the current CU are coded. It is well known that the HEVC adopts CTU and CU block structure as basic units for coding video data. Each picture is divided into CTUs and each CTU is reclusively divided into CUs. During prediction phase, each CU may be divided into multiple blocks, named prediction units (PUs) for performing prediction process. After prediction residue is formed for each CU, the residue associated with each CU is divided into multiple blocks, named transform units (TUs) to apply transforms.
In JCTVC-M0350, the Intra MC is different from the motion compensation used for Inter prediction in at least the following areas:                MVs are restricted to be 1-D for Intra MC (i.e., either horizontal or vertical) while Inter prediction uses 2-D motion estimation.        Binarization is fixed length for Intra MC while Inter prediction uses exponential-Golomb.        Intra MC introduces a new syntax element to signal whether the MV is horizontal or vertical.        
Based on JCTVC-M0350, some modifications are disclosed by Pang, et al. in Non-RCE3: Intra Motion Compensation with 2-D Mvs, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Vienna, AT, 25 Jul.-2 Aug. 2013, Document: JCTVC-N0256 (hereinafter JCTVC-N0256). Firstly, the Intra MC is extended to support 2-D MVs, so that both MV components can be non-zero at the same time. This provides more flexibility to Intra MC than the original approach, where the MV is restricted to be strictly horizontal or vertical.
In JCTVC-N0256, two MV coding methods are disclosed:                Method 1: Motion vector prediction. The left or above MV is selected as the MV predictor and the resulting motion vector difference (MVD) is coded. A flag is used to indicate whether the MVD is zero. When MVD is not zero, exponential-Golomb codes of the 3rd order are used to code the remaining absolute level of the MVD. Another flag is used to code the sign.        Method 2: NoMotion vector prediction. The MV is coded using the exponential-Golomb codes that are used for MVD in HEVC.        
Another difference disclosed in JCTVC-N0256 is that the 2-D Intra MC is further combined with the pipeline friendly approach:                1. No interpolation filters are used,        2. MV search area is restricted. Two cases are disclosed:                    a. Search area is the current CTU and the left CTU or            b. Search area is the current CTU and the rightmost 4 column samples of the left CTU.                        
In JCTVC-R0309 (Pang et al., Non-SCCE1: Combination of ICTVC-R0185 and JCTVC-R0203, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, JP, 30 Jun.-9 Jul. 2014, Document: JCTVC-R0309), the BV coding is modified to use the neighboring BVs and coded BVs as BV predictor (BVP). The BVP technique has been adopted in SCM 2.0 (HEVC Screen Content Coding Test Model 2.0). The BV predictor is derived similar to the AMVP (advanced motion vector prediction) scheme in HEVC. The predictor candidate list is constructed by first checking the available of block vector from the spatial neighboring blocks A1 and B1 according to a priority order as shown in FIG. 2. If one or both of the spatial neighboring blocks contain no block vector, one or both of the last two coded BVs are used to fill into the block vector candidate list. The replacement block vectors are initialized with (−2*CU_width, 0) and (−CU_width, 0). To avoid the need of line buffer, the above BV outside the current CTU is considered unavailable. The last two coded BVs are reset to (0, 0) for each CTU to prevent the data dependency.
In U.S. Provisional Patent Application, Ser. No. 62/044,385, a method of Merge mode for IntraBC mode is disclosed, where the Merge index points to an IntraBC coded Merge candidate. In some cases, a BVP may be pointing to an invalid block. FIG. 3A illustrates one example of BVP pointing to an invalid block. In FIG. 3A, the block vector predictor 312 points from previous processed block 314 shown as a solid square to reference block 316 shown as a dashed square. If the current block vector 322 uses block vector 312 as a predictor, the current block 324 shown as a solid square would point to reference area 326 shown as a dashed square. As shown in FIG. 3A, half of the reference block 326 for the current block is in the current block, which is not reconstructed yet. FIG. 3B illustrates another example of BVP pointing to an invalid block. In FIG. 3B, the block vector predictor 332 points from previous processed block 334 shown as a solid rectangle to reference block 336 shown as a dashed rectangle. If the current block vector 342 uses block vector 332 as a predictor, the current block 344 shown as a solid rectangle would point to reference area 346 shown as a dashed rectangle. As shown in FIG. 3B, half of the reference block 346 is in the area that is not processed yet.
Therefore, some constraints should be imposed on the block vector predictor to assure a valid block vector for the current IntraBC block. In particular, the x-axis component and/or y-axis component of the block vector predictor should meet some requirements.
Recently, a technique called adaptive motion vector resolution has been proposed to HEVC SCC (screen content coding) by Li et al., in JCTVC-50085 (Li et al., Adaptive motion vector resolution for screen content, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 19th Meeting: Strasbourg, FR, 17-24 Oct. 2014, Document: JCTVC-50085), where a slice level flag is used to indicate whether the resolution of MV for the inter coded PUs are at integer accuracy or ¼-pel accuracy. In U.S. Provisional Patent Applications, Ser. No. 61/942,819 and Ser. No. 61/954,181, the current picture is treated as one of the reference pictures for IntraBC operations. This current picture is placed into the reference picture list or to replace one existing reference picture in the list.
As mentioned before, in the current SCM (HEVC Screen Content Coding Test Model), the block vectors always use integer resolution while motion vectors can be integer resolution and quarter-pel resolution. There are differences in the derivation process between the block vector and motion vector. The corresponding text description of BV and MV derivation is listed in Tables 1A, 1B and 1C as follows.
TABLE 1AWhen predFlagLX is equal to 1 and the picture with index refIdx fromreference picture list LX of the slice is not the current picture, the lumamotion vector mvLX is derived as follows:uLX[ 0 ] = ( mvpLX[ 0 ] + mvdLX[ 0 ] + 216 ) % 216mvLX[ 0 ] = ( uLX[ 0 ] >= 215 ) ? ( uLX[ 0 ] − 216 ) : uLX[ 0 ]uLX[ 1 ] = ( mvpLX[ 1 ] + mvdLX[ 1 ] + 216 ) % 216mvLX[ 1 ] = ( uLX[ 1 ] >= 215 ) ? ( uLX[ 1 ] − 216 ) : uLX[ 1 ]
TABLE 1BWhen predFlagLX is equal to 1 and the reference picture is the currentpicture, the luma motion vector mvLX is derived as follows:uLX[ 0 ] = ( ( ( mvpLX[ 0 ] >> 2 ) + mvdLX[ 0 ] ) << 2 + 216 ) % 216mvLX[ 0 ] = ( uLX[ 0 ] >= 215 ) ? ( uLX[ 0 ] − 216 ) : uLX[ 0 ]uLX[ 1 ] = ( ( mvpLX[ 0 ] >> 2 ) + mvdLX[ 0 ] ) << 2 + 216 ) % 216mvLX[ 1 ] = ( uLX[ 1 ] >= 215 ) ? ( uLX[ 1 ] − 216 ) : uLX[ 1 ]
The resulting values of mvLX[0] and mvLX[1] as specified above will always be in the range of −215 to 215−1, inclusive. In Table 1A and Table 1B, predFlagLX is a flag indicating whether the prediction of a corresponding block may be derived from a reference picture list L0 or a reference picture list L1. When predFlagLX is equal to 1, it indicates that the prediction of a corresponding block may be derived from a reference picture list L0 or a reference picture list L1. Table 1A corresponds to the derivation of motion vectors for inter prediction coded blocks. Table 1B corresponds to the derivation of block vectors for IntraBC coded blocks. Since the integer-valued BV are stored in quarter-pel resolution, the BV has to be right-shifted by 2 to derive the integer value before BV is used as a predictor as shown in Table 1B. In the above tables, mvpLX[0] and mvpLX[1] correspond to the motion/block vector components associated with the motion/block vector predictor, and mvdLX[0] and mvdLX[1] correspond to the motion/block vector differences between the current motion/block vector and the motion/block vector predictor in list LX, where X is equal to 0 or 1.
Before applying interpolation, the derived motion vector is clipped when the integer resolution is selected for an inter prediction coded block as shown in Table 1C.
TABLE 1CWhen use_integer_mv_flag is equal to 1 and the referenceindex refIdxLX is not equal to currPic, mvLX and mvCLX(where X equals to 0 or 1) are modified as follows:mvLX = Clip3( − 215, 215 − 1, mvLX << 2 )mvCLX = Clip3( − 215, 215 − 1, mvCLX << 2 )
The resolution of motion vector is indicated by “use_integer_mv_flag”. The syntax table for this flag is incorporated in the slice header as shown below.                if(motion_vector_resolution_control_idc==2)                    use_integer_mv_flag.                        
The syntax, motion_vector_resolution_control_idc is signaled in sequence parameter set (SPS) to indicate the motion vector resolution modes. Three modes are defined. When the mode is 0, all motion vectors in the sequence are at ¼ pixel resolution (i.e., quarter-pel resolution). When the mode is 1, all of the motion vectors in the sequence are encoded at full pixel resolution (i.e., integer resolution). Furthermore, motion_vector_resolution_control_idc equal to 2 specifies that use_integer_mv_flag may be signaled at slice header to select integer or quarter-pel resolution adaptively. The flag, use_integer_mv_flag equal to 1 specifies that the motion vector resolution is integer in the decoding process of current slice. use_integer_mv_flag equal to 0 specifies that the motion vector resolution is quarter-pixel (i.e., quarter-pel) in the decoding process of current slice. When not present, the value of use_integer_mv_flag is inferred to be equal to motion_vector_resolution_control_idc.
When use_integer_mv_flag is equal to 1, all motion vectors in the slice will be decoded in integer resolution, and stored in integer-pel resolution. When use_integer_mv_flag is equal to 0, all motion vectors in the slice will be decoded in quarter-pel resolution and stored in quarter-pel resolution. When integer MV is used for a slice, all the stored MVs will be left shifted by two, before motion compensation (interpolation) stage. An issue may occur in the deblocking filter stage, where MV is used as a parameter for boundary strength (BS) decision. It is required that the MV of a block in deblocking is in quarter-pel resolution. In addition, when the stored MV is used as a predictor for MV prediction, the predicted MV and its predictor may not have the same resolution. Therefore, a resolution mismatch issue exists due to adaptive motion vector resolution.
In High Level Syntax, the current picture is placed after all short term reference pictures and all other long term reference pictures during the initialization of reference picture list construction. The related descriptions are listed below for List 0. Similar process can be applied for List 1.
At the beginning of the decoding process for each slice, the reference picture list RefPicList0 for P slices and, both reference picture lists RefPicList0 and RefPicList1 for B slices are derived as follows:
TABLE 2At the beginning of the decoding process for each slice,the reference picture lists RefPicList0 and RefPicList1(used for B slices) are derived as follows:NumRpsCurrTempList0 is set toMax( num_ref_idx_l0_active_minus1 + 1,NumPicTotalCurr ) and the list RefPicListTemp0 is constructedas follows:rIdx = 0while( rIdx < NumRpsCurrTempList0 ) {for( i = 0; i < NumPocStCurrBefore && rIdx < NumRpsCurrTempList0;rIdx++, i++ )  RefPicListTemp0[ rIdx ] = RefPicSetStCurrBefore[ i ]for( i = 0; i < NumPocStCurrAfter && rIdx < NumRpsCurrTempList0;rIdx++, i++ )  RefPicListTemp0[ rIdx ] = RefPicSetStCurrAfter[ i ]for( i = 0; i < NumPocLtCurr && rIdx < NumRpsCurrTempList0;rIdx++, i++ )    RefPicListTemp0[ rIdx ] = RefPicSetLtCurr[ i ]if( curr_pic_as_ref_enabled_flag )    RefPicListTemp0[ rIdx++ ] = currPic}
In Table 2, curr_pic_as_ref_enabled_flag equal to 1 specifies a picture referring to the SPS (sequence parameter set) may be included in a reference picture list of the picture itself. curr_pic_as_ref_enabled_flag equal to 0 specifies that a picture referring to the SPS is never included in any reference picture list of the picture itself. When not present, the value of curr_pic_as_ref_enabled_flag is inferred to be equal to 0.
After the initialization, the reference picture list RefPicList0 is constructed as follows:                for(rIdx=0; rIdx<=num_ref_idx_10_active_minus1; rIdx++)                    RefPicList0[rIdx]=ref_pic_list_modification_flag_10 ?                            RefPicListTemp0[list_entry_10[rIdx]]: RefPicListTemp0[rIdx].                                                
However, when the number of active reference pictures (i.e., num_ref_idx_10_active_minus1+1) is smaller than the the number of reference pictures in the list (NumRpsCurrTempList0) associated with the RefPicListTemp0 array storing the current picture, the current picture may not be included in the active reference picture list.
In a coding system based on the existing HEVC, there is an issue associated with Decoded Picture Buffer (DPB) management for IntraBC. When IntraBC is used, the reconstructed portion of current picture may be used as a reference picture to predict current picture. This reference picture for IntraBC is referred as “the unfiltered version of current picture”. On the other hand, the version of current picture that will eventually go through filtering operations such as deblocking and SAO is referred to the filtered version of current picture.
A reference picture has to be in Decoded Picture Buffer (DPB) in order to be used by a current picture. The size of DPB is constrained to be MaxDpbSize, which is derived as shown in Table 3.
TABLE 3if( PicSizeInSamplesY <= ( MaxLumaPs >>2 )    MaxDpbSize = Min( 4 * maxDpbPicBuf, 16 )else if( PicSizeInSamplesY <= ( MaxLumaPs >> 1 )    MaxDpbSize = Min( 2 * maxDpbPicBuf, 16 )else if( PicSizeInSamplesY <= ( ( 3 * MaxLumaPs ) >> 2 ) )    MaxDpbSize = Min( ( 4 * maxDpbPicBuf ) / 3, 16 )Else    MaxDpbSize = maxDpbPicBuf
In Table 3, MaxLumaPs is the maximum luma picture size and maxDpbPicBuf is is the maximum DPB size such as 6. However, there are some issues in the current DPB management operations when IntraBC is used (current picture as reference picture).
It is desirable to develop techniques to resolve issues associated with adaptive motion vector resolution when blocks in a slice are coded in the IntraBC mode and inter prediction mode.